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I. Real Party in Interest 

The real party in interest in this appeal is FirstWeb Bancorp., Inc., a corporation of the 
state of California, which is the owner of the present application by written assignment recorded 
at reel/frame number 012241/0822. 

II. Related Appeals and Interferences 

There are no other appeals or interferences that relate to this one known to Applicant. 

III. Status of Claims 

Claims 1-10 and 26-28 stand rejected under 35 U.S.C. 102(e), in view of Elgamal. 
Claims 28-30 stand rejected under 35 U.S.C. § 103(a) in view of the combination of Elgamal and 
Jennings. Each of the claims' rejection is appealed. 

IV. Status of Amendments 

No amendments have final rejection have been entered. 

V. Summary of Claimed Subject Matter 

Claim 1: 

Claim 1 is directed to system for the transfer of actual funds, using push-model transfers. 
Due to its novel features, it permits private and secure transactions that can be finalized much 
more promptly than prior art systems, such as Elgamal or ECH transactions. 

Claim 1 reads as follows: A system [100] for performing push-model fund transfers 
between at least one user [199] and at least one payor [101], the system comprising: 
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at least one payor interface comprising software operative to permit the at least one payer 
to provide information identifying a desired fund transfer; 

a gateway [120] having at least one gateway account, said gateway being operative: 
to receive said information; 

to receive incoming funds from the payor [101] via a push-model transfer into 
said at least one gateway account after receiving said information; 

to inform the user that the payor [101] has provided an appropriate amount of 

funds via a push-model transfer if said incoming funds received are of an 
appropriate amount according to said desired fund transfer; and 

to send corresponding outgoing funds to the user after receiving said incoming 
funds. 

The general relationship between the user, the payor, and the gateway is discussed on pp. 
11-12 of the specification, and shown in Figs, la and lb, in the context of an embodiment in 
which the user is a merchant and the payor is a customer. An alternative embodiment, in which 
the user is a student and the payor is a family member (e.g. parents) is shown in Fig. 2, and 
described generally in the specification at pp. 14-15. The functionality of gateway 120 is 
described in greater detail throughout pages 11-19, and in the text of the originally filed claims. 
The identification of a desired fund transfer is described generally at pages 12-13. The receiving 
of incoming funds via push-model transfer (from the payor's financial institution 130a) is 
described generally in the last paragraph on page 12. The informing of the user that the payor 
has provided an appropriate amount of funds is described generally in the following paragraph, 
on page 13, as is the sending of corresponding outgoing funds. 

Page 3 of 23 
Appeal Brief 
Serial No. 09/929,460 



Claim 10: 

Claim 10 is directed to a system for performing push-model fund transfers between a 
plurality of merchants and at least one payor. The system of Claim 10 shares the novel features 
of Claim 1, which provide it with the same advantageous ability to provide private, secure, and 
more promptly final transactions, relative to prior systems. It also includes additional features 
that assist in performing that function. 

Claim 10 reads as follows: 

A system [100] for performing push-model fund transfers between a plurality of 
merchants [199] and at least one payor [101], the system comprising: 

at least one merchant website [110] operative to permit the at least one payor [101] to 

provide information identifying a desired fund transfer, including the payor [101], 
a payee-merchant, and an amount of funds to be transferred; 
a gateway [120] comprising a gateway bank [122], said gateway bank having at least one 
gateway account, said gateway being operative: 
to receive said information from said at least one merchant website; 
to calculate an appropriate amount of incoming funds corresponding to said 

amount of funds to be transferred; 
to provide deposit information to the at least one payor [101] sufficiently 

identifying said gateway account to permit the payor [101] to cause said 
appropriate amount of incoming funds to be deposited in said at least one 
gateway account; 
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to receive incoming funds from the payor [101] into said at least one gateway 

account after receiving said information; 
to inform the payee-merchant that the payor has provided said appropriate amount 
of incoming funds if said incoming funds received are of said appropriate 
amount of incoming funds; and 
to send outgoing funds in said amount of funds to be transferred to the payee- 
merchant after receiving said incoming funds. 
The role of the merchant website is described in the last full paragraph of page 12. 
The general relationship between the user, the payor, and the gateway is discussed on pp. 
11-12 of the specification, and shown in Figs, la and lb, in the context of an embodiment in 
which the payor is a customer. An alternative embodiment, in which the user is a student and the 
payor is a family member (e.g. parents) is shown in Fig. 2, and described generally in the 
specification at pp. 14-15. The functionality of gateway 120 is described in greater detail 
throughout pages 11-19, and in the text of the originally filed claims. The identification of a 
desired fund transfer is described generally at pages 12-13. The receiving of incoming funds via 
push-model transfer (from the payor's financial institution 130a) is described generally in the last 
paragraph on page 12. Calculating an appropriate amount of incoming funds is described, in the 
context of an international transfer in which the user wishes to affect a transfer of a specific 
amount of foreign currency, in the last paragraph of page 16. (This is in the context of a transfer 
to a domestic student from a family abroad, but it will be appreciated that the same principle 
applies for an international purchase.) A first embodiment of providing of deposit information to 
the at least one payor is described in the last paragraph of page 12 (in which the gateway 
provides an interface to create the credit transfer), and second embodiment is described in the 
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first paragraph on page 16 (in which the means of affecting the transfer is unspecificied). In both 
cases, the receipt of the incoming funds is discussed in conjunction with the providing of deposit 
information. The informing of the user that the payor has provided an appropriate amount of 
funds is described in the context of the first embodiment is described in the first full paragraph 
on page 13, and in the context of the second embodiment on the first full paragraph on page 16. 
The sending of corresponding outgoing funds is described at the same places. 

Claim 26: 

Claim 26 is directed to a system for performing push-model fund transfers between at 
least one user and at least one payor. 
Claim 26 reads as follows: 

A system [100] for performing push-model fund transfers between at least one user and at 
least one payor [101], the system comprising: 
at least one payor interface; 

a gateway [120] having at least one gateway account, said gateway being operative: 
to receive information identifying a desired fund transfer; 
to receive incoming funds via a remote deposit from the payor into said at least 

one gateway account after receiving said information; 
to inform the user that the payor has provided an appropriate amount of funds if 

said incoming funds received are of an appropriate amount according to 

said desired fund transfer; and 
to send corresponding outgoing funds to the user after receiving said incoming 

funds. 

Page 6 of 23 
Appeal Brief 
Serial No. 09/929,460 



#511029 

The general relationship between the user, the payor, and the gateway is discussed on pp. 
11-12 of the specification, and shown in Figs, la and lb, in the context of an embodiment in 
which the user is a merchant and the payor is a customer. An alternative embodiment, in which 
the user is a student and the payor is a family member (e.g. parents) is shown in Fig. 2, and 
described generally in the specification at pp. 14-15. The functionality of gateway 120 is 
described in greater detail throughout pages 11-19, and in the text of the originally filed claims. 
The identification of a desired fund transfer is described generally at pages 12-13. The receiving 
of incoming funds via push-model transfer (from the payor's financial institution 130a) is 
described generally in the last paragraph on page 12. The informing of the user that the payor 
has provided an appropriate amount of funds is described generally in the following paragraph, 
on page 13, as is the sending of corresponding outgoing funds. 

VI. Grounds of Rejection for Appeal 

Rejections Under §102 

Claims 1-10 and 26-28 stand rejected under 35 U.S.C. § 102(e) as being anticipated by 
Elgamal, U.S. Patent No. 6,138,107. It is respectfully submitted that, while the Elgamal patent 
describes a system for the transfer of funds over a computer network (such as the Internet), it 
does not anticipate the system disclosed and claimed in the instant application. 

Rejections Under §103 

Claims 28-30 stand rejected under 35. U.S.C. § 103(a) as obvious in view of Elgamal and 
U.S. Patent No. 5,659,165 to Jennings. 
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VII. Argument 

Rejections Under §102 

Elgamal teaches a system that differs fundamentally from the claimed invention. In 
Elgamal, fund transfers are accomplished via a conversion process, in which real currency is 
converted into a pseudo-currency (referred to in the Elgamal patent as "electronic money"). See, 
e.g., col. 6, 11. 20-25; col. 7, 11. 30-40. The "electronic money" is, in effect, an accounting system 
used by Elgamal' s system to track a large number of small transactions 
("microtransactions") — in fact, the purpose of Elgamal' s invention was to facilitate such 
microtransactions. See Elgamal, "Summary of the Invention," col. 5, 11. 20-24. The instant 
invention was created to solve a different problem, operates in a different fashion, and does not 
convert real currency into pseudo-currency. 

More specifically, Claims 1 and 10 of the instant application explicitly require: "a 
gateway . . . operative ... to receive incoming funds from the payor . . . ; to inform the user that the 
payor has provided an appropriate amount of funds; and to send corresponding outgoing funds 
to the user ... ." It should be noted that the funds are transferred from the payor into "said at 
least one gateway account," whereupon the gateway "inform[s] the user that the payor has 
provided an appropriate amount of funds." 

According to the Final Office Action, Elgamal teaches that the gateway can receive 
incoming funds from the payor via a push-model transfer at col. 6, lines 23-26. However, those 
lines explicitly state, to the contrary, that what is deposited is the "electronic money" — not actual 
funds. These funds are presumably purchased with actual funds (in the purchase transaction 
described at lines 22-23). There is, however, no indication whatever that they are purchased by 
anything other than the usual ACH type transaction, nor does Elgamal explain how such a 
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purchase could be accomplished through a push-model transaction. For example, Elgamal does 
not discuss the functionality of the software that would be required, nor the requisite nodes for 
the exchange of the necessary information. 

Elgamal itself notes this limitation, at col. 7, lines 45-52 

"[E]ach transaction consists of a purchase order and an optional acknowledgement. The 
acknowledgement is optional in that acceptance of the purchase order is all that is needed 
to initiate the provision of the requested service, goods, or EMA. In an alternative 
implementation, the recipient of a purchase order can return a denial if it did not accept 
the purchase order, rather than with an acknowledgment if it did." 

Put another way, prior systems such as Elgamal convert actual funds into a pseudo-currency. 

The claimed invention completes the transactions without the need to do so. A key advantage of 

the Claimed invention over prior art such as Elgamal is that provision of the requested service, 

goods, or EMA is initiated after actual funds have been provided through a push-model transfer, 

since such a transfer can promptly assure the merchant (or service or other provider) that they 

will ultimately be compensated. The Claimed invention is likewise superior to a standard ACH 

transaction (such as a credit card purchase), in which a payment can be reversed up to 60 days 

after the transaction is initiated. 

Another advantage of the instant invention is improved privacy and security, because the 

payor need not provide information identifying his or her bank account, credit card number, or 

other such information. All that is necessary is that the payor set in motion the push-model 

transfer of funds, by whatever mechanism preferred (such as wire transfer). On the other hand, 

the instant invention provides for superior transfer of information between user and payor over 

that embedded in current domestic or international fund transfers. 
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Claim 26 specifically requires that the gateway be operative to "receive incoming funds 
via a remote deposit from the payor." As discussed above with respect to Claims 1 and 10, the 
cited references do not teach or suggest the use push-model transfers to deposit actual funds. 

Applicant respectfully submits that, because they fail to teach or suggest the use of push- 
model transfers, the cited references do not anticipate the claims. 

Rejections Under §103 

Claims 28-30 stand rejected under 35. U.S.C. § 103(a) as obvious in view of Elgamal and 
U.S. Patent No. 5,659,165 to Jennings. 

As noted by the Final Office Action, to evaluate whether a claimed invention is obvious, 
the following factual inquiries must be made: 

(1) Determining the scope and content of the prior art; 

(2) Ascertaining the differences between the claimed invention and the prior art; and 

(3) Resolving the level of ordinary skill in the pertinent art. 

(4) Considering objective evidence present in the application indicating obviousness or 

nonobviousness. 

The Final Office Action asserts invalidity under § 103 on the grounds that it would have 
been obvious to combine an engine that computes currency conversions with the other features 
of Claim 26. However, since the Office Action erroneously contended that the other features of 
Claim 26 were all present in Elgamal, it failed to address the fact that the elements of Claim 26 
absent from the prior art are non-obvious, and, therefore patentable distinctions over it. 

Specifically, as discussed above with respect to the rejections under 35 U.S.C. § 102, the 
prior art does not teach or suggest a system that uses the deposit of actual funds through a push- 
model transfer, such that a private, secure, and final transaction can be accomplished much more 
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quickly than in the prior art. Thus, points (1) and (2) above tend to demonstrate the non- 
obviousness of Claim 26. 

Regarding point (3), the level of skill in the art, it should be recognized that it is 
substantially lower than that of those who created and maintain the electronic banking system 
through with ACH transactions are routed. The claimed invention employs that system, but to 
reproduce it is far beyond the scope of the claimed invention. Rather, the claimed invention 
provides specific, non-trivial additional functionality, which is advantageous in certain specific 
respects (as discussed above, particularly where privacy and rapid finality are desired). It is 
submitted that the level of ordinary skill in the art is approximately a few years of experience in 
the finance industry, and a bachelor's degree, not necessarily in a field relating to the finance 
industry. This level of skill in the art also tends to show that Claim 26 is not obvious, since 
systems that work symbiotically with the electronic banking system to complete transactions 
with actual funds, rather than through accounting practices, as in Elgamal, are, as far as 
Applicant is aware — unheard of. If such a system does exist, it has not been made of record in 
this application. Regardless, the Office Action fails to even address this element of the analysis, 
much less explain why it supports a finding of obviousness. 

It should also be noted that none of the rationales discussed in the PTO's Examination 
Guidelines for Determining Obviousness support a finding of obviousness. As discussed above, 
the claimed invention is not merely a combination of elements of the prior art, nor is it the 
product of a simple substitution of an element in the cited art. The claimed invention does not 
merely use a known technique, much less one used to improve similar systems, or to produce 
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predictable results. 1 The invention was not an "obvious to try" option from a finite, identified 
predictable solutions. No suggestion or motivation to modify Elgamal to produce the claimed 
invention has been found or cited, nor other known work in the field that prompted the 
modification of Elgamal (or any other reference) to produce the claimed invention. 

It should be noted that, for essentially similar reasons, Claims 1-10 are not obvious in 
view of Elgamal, either alone or in combination with Jennings. (Claims 1-10 have not been 
rejected under § 103, but, in view of their rejection under § 102, one might expect, a fortiori, the 
assertion of obviousness as well.) 

VIII. Claims Appendix 

1 . (Previously Amended) A system for performing push-model fund transfers between at 
least one user and at least one payor, the system comprising: 

at least one payor interface comprising software operative to permit the at least one payer 
to provide information identifying a desired fund transfer; 

a gateway having at least one gateway account, said gateway being operative: 
to receive said information; 

to receive incoming funds from the payor via a push-model transfer into said at 
least one gateway account after receiving said information; 



1 Application of the "predictable results" rationale must focus on the "known technique" 
requirement, especially in the context of software or software system inventions. Because 
software inventions may be defined in terms of their functionality — since it is understood that, 
once their functionality is identified, those skilled in the art are enabled to make and use it — by 
rigorous definition their results are predictable. 
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to inform the user that the payor has provided an appropriate amount of funds via 
a push-model transfer if said incoming funds received are of an 
appropriate amount according to said desired fund transfer; and 

to send corresponding outgoing funds to the user after receiving said incoming 
funds. 

2. (Original) The system of claim 1, wherein said software is a website. 

3. (Original) The system of claim 2, wherein the at least one user is a plurality of merchants, 
and each merchant has an associated website. 

4. (Original) The system of claim 1, wherein said gateway comprises a gateway bank, and 
said gateway account is an element of said gateway bank. 

5. (Original) The system of claim 1, wherein said information comprises an amount of funds 
to be transferred, the payor, and the user that is to be a payee of said desired fund transfer. 

6. (Original) The system of claim 1, wherein said gateway provides deposit information to 
the at least one payor sufficiently identifying said gateway account to permit the payor to cause 
funds to be deposited therein. 
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7. (Original) The system of claim 6, wherein the payor must cause funds to be deposited in 
said gateway account by ordering a financial institution with which the payor has an account to 
transfer funds into said gateway account. 

8. (Original) The system of claim 7, wherein the payor orders said financial institution with 
which the payor has an account to transfer funds into said gateway account using an ACH credit 
to said gateway account. 

9. (Original) The system of claim 1, wherein an amount of said corresponding outgoing 
funds is determined by the payor and the user, and said appropriate amount of said incoming 
funds is selected by said gateway based on said amount of said corresponding outgoing funds 
such that said gateway retains some of said incoming funds. 

10. (Previously Amended) A system for performing push-model fund transfers between a 
plurality of merchants and at least one payor, the system comprising: 

at least one merchant website operative to permit the at least one payor to provide 

information identifying a desired fund transfer, including the payor, a payee- 
merchant, and an amount of funds to be transferred; 

a gateway comprising a gateway bank, said gateway bank having at least one gateway 
account, said gateway being operative: 

to receive said information from said at least one merchant website; 
to calculate an appropriate amount of incoming funds corresponding to said 
amount of funds to be transferred; 
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to provide deposit information to the at least one payor sufficiently identifying 

said gateway account to permit the payor to cause said appropriate amount 
of incoming funds to be deposited in said at least one gateway account; 

to receive incoming funds from the payor via a push-model transferjnto said at 
least one gateway account after receiving said information; 

to inform the payee-merchant that the payor has provided said appropriate amount 
of incoming funds via a push-model transfer if said incoming funds 
received are of said appropriate amount of incoming funds; and 
to send outgoing funds in said amount of funds to be transferred to the payee-merchant after 
receiving said incoming funds. 

1 1 . (Withdrawn) A system for transferring funds from a foreign source of funds to a domestic 
student having a student's account, the system comprising: 

a gateway having at least one domestic gateway account; 

at least one foreign account operative to receive incoming funds from the source of funds 
in a first currency, and to inform said gateway of a first quantity of said incoming 
funds after said incoming funds have been received; 

a gateway interface comprising software and operative to permit the student to request a 
fund transfer through said gateway by identifying the student's account, the 
source of funds, and a desired quantity of funds to be transferred; 

wherein said gateway transfers a corresponding second quantity of funds in said first 

currency from said gateway account to the student account in a second currency 
after being informed of said first quantity. 
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12. (Withdrawn) The system of claim 11, wherein said gateway comprises a federally insured 
gateway bank, and said gateway domestic account is an element of said gateway bank. 

13. (Withdrawn) The system of claim 11, wherein said at least one foreign account is an 
account with a correspondent bank that provides accounts in at least one foreign country. 

14. (Withdrawn) The system of claim 11, wherein said software comprises a website 
operative to receive as input a desired first quantity and to display a calculation providing the 
corresponding second quantity, and to receive as input a desired second quantity and to display a 
calculation providing the corresponding first quantity. 

15. (Withdrawn) The system of claim 11, wherein said domestic account is an account in the 
United States, and second currency is U.S. dollars. 

16. (Withdrawn) The system of claim 11, wherein said foreign account transfers funds to said 
gateway account after informing said gateway of said first quantity. 

17. (Withdrawn) The system of claim 16, wherein said foreign account is operative to receive 
incoming funds from a plurality of sources of funds, and to transfer funds to said gateway 
account after said incoming funds have accumulated to more than a pre-determined quantity. 
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18. (Withdrawn) The system of claim 17, wherein said pre-determined quantity is determined 
by a quantity necessary to receive a superior rate of exchange between said first and second 
currencies. 

19. (Withdrawn) A system for transferring funds from a plurality of sources of funds, each 
source of funds being in a corresponding foreign country, to a plurality of students in the United 
States, each student having a student's account, the system comprising: 

a gateway comprising a federally insured gateway bank, the gateway bank including at 

least one gateway account in the United States; 
at least one correspondent bank providing at least one foreign account in each of the 

corresponding foreign countries, the at least one foreign account being operative 

to receive incoming funds in a first currency and from at least one source of 

funds, and to inform said gateway of a first quantity of said incoming funds after 

said incoming funds have been received; 
a website, operative to permit the students to request fund transfers through said gateway, 

each of said fund transfers being requested by one of the students by identifying 

the student's account, the student's source of funds, and a desired quantity of 

funds to be transferred; 
wherein said gateway transfers a corresponding second quantity of funds in said first 

currency from said gateway account to the student account in a second currency 

after being informed of said first quantity; and 
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wherein said at least one correspondent bank exchanges funds in foreign currencies for U.S. 
dollars after sufficient incoming funds have accumulated to permit the at least one correspondent 
bank to receive a superior rate of exchange and transfers the U.S. dollars to the gateway bank. 

20. (Withdrawn) A system for performing push-model fund transfers, the system being in 
communication with the Internet and comprising: 

a customer front-end, adapted to enable a customer to enroll in the system, to request a 

fund transfer, and to observe information regarding the fund transfer, the 

customer front end also being adapted to generate and to transmit a transaction 

corresponding to the fund transfer; 
a customer service front-end, adapted to enable system operators to observe information 

regarding the fund transfer; 
an operations front-end, adapted to enable a system operator to observe information 

regarding settlements and returns; 
a treasury front-end, adapted to enable a treasury operator to update currency conversion 

rates, customer fees, adjust risk parameters, and correspondent bank account 

numbers; 

an OFAC filter, adapted to download and import an OFAC database from the Internet 

into the system; 
an FX engine, comprising: 

an FX transaction database; 

a user database; 
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an acquiring system, adapted to accept the transaction request from the customer 
front end, to perform an OFAC check on the accepted transaction request 
using the OFAC database downloaded by the OFAC filter, and to store a 
transaction record in the FX transaction database if the OFAC check on 
the transaction request is passed, the transaction record containing 
information regarding a transaction; 

an FX XML agent, adapted to read a transaction record from the FX transaction 
database, to create a corresponding XML file, and to send the 
corresponding XML file to the transfer engine; 

an e-mail agent, adapted to send an e-mail message to a customer when the 

customer enrolls in the system, when a transaction is requested, and when 
a transaction is confirmed; 

a plurality of front-end servers, comprising: 

an event server, adapted to pass a status of a transaction; 
a user server, adapted to pass information regarding an enrollment; 
a transaction ID server, adapted to generate a unique number for each 
transaction; 

a signing server, adapted to perform a security check on each transaction; 
a currency manager, comprising: 

a rate server, adapted to read the currency exchange rate from the FX 
database; 

a rate agent, adapted to pass information from the treasury front-end; 
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the FX engine being adapted to respond to requests for fund transfers by 

performing currency conversion using the currency conversion rates, by 
entering corresponding records in the user and FX transaction database, by 
submitting transactions to the transfer engine, and by causing status 
emails to be sent to customers; 
an transfer engine, comprising: 

a transfer processor; 

a transfer database; 

wherein the transfer processor is adapted to perform on-line payment systems 
interface processing, batch payment system interface processing, and 
exception processing; 

a risk management module, adapted to use the risk parameters to impose velocity limits 
on requests for fund transfers. 

21. (Withdrawn) The system of claim 20, wherein the transfers are performed via the ACH 
network. 

22. (Withdrawn) The system of claim 20, wherein the transfers are performed via the ATM 
network. 

23. (Withdrawn) A system for performing push-model fund transfers between comprising a 
transaction previewer that enables a user to select and input one of the set consisting of a desired 
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amount of currency to be sent and a desired amount of currency to be received, and to then 
display a complete calculation including each other element of the transaction. 

24. (Withdrawn) The system of claim 23, wherein the currencies can be those of any of a 
plurality of nationalities, and wherein one element of the transaction that is displayed by the 
transaction previewer is the exchange rate between a nationality of currency to be sent and a 
nationality of currency to be received. 

25. (Withdrawn) The system of claim 23, wherein the transaction previewer comprises an 
Internet website. 

26. (Original) A system for performing push-model fund transfers between at least one user 
and at least one payor, the system comprising: 

at least one payor interface; 

a gateway having at least one gateway account, said gateway being operative: 
to receive information identifying a desired fund transfer; 
to receive incoming funds via a remote deposit from the payor into said at least 

one gateway account after receiving said information; 
to inform the user that the payor has provided an appropriate amount of funds if 

said incoming funds received are of an appropriate amount according to 

said desired fund transfer; and 
to send corresponding outgoing funds to the user after receiving said incoming 

funds. 
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27. (Original) The system of claim 26, wherein said at least one payer interface comprises 
software adapted to permit the payor to provide said information. 

28. (Original) The system of claim 27, wherein said at least one payer interface further 
comprises a transaction previewer that enables a user to select and input one of the set consisting 
of a desired amount of currency to be sent and a desired amount of currency to be received, and 
to then display a complete calculation including each other element of the transaction. 

29. (Original) The system of claim 26, wherein the funds can be currencies of any of a 
plurality of nationalities. 

30. (Original) The system of claim 29, wherein the currencies can be of any of a plurality of 
nationalities, and one element of the transaction that is displayed by the transaction previewer is 
the exchange rate between a nationality of currency to be sent and a nationality of currency to be 
received. 

IX. Evidence Appendix 

No evidence has been submitted in this application pursuant to §§ 1.130-32. 

X. Related Proceedings Appendix 

As discussed above in Part II, there are no related proceedings. 
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Conclusion 

Applicant respectfully requests reconsideration and the issuance of a timely Notice of 
Allowance for the pending claims. If the Examiner believes that there are any matters that can 
be resolved by a telephonic interview, the undersigned would welcome a telephone call. 



Respectfully submitted: 



/s/Quentin G. Cantrell 

Quentin G. Cantrell, Reg. No. 47,469 
Woodard, Emhardt, Moriarty, 
McNett & Henry, LLP 
111 Monument Circle, Suite 3700 
Indianapolis, Indiana 46204-5137 
(317) 634-3456 
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